The present invention relates to a method of developing a software system using Object Oriented Technology and frameworks, in particular relates to a method for providing a framework supporting flexible interchange of domain algorithms.
In order to maintain or enlarge their competitiveness, enterprises of almost every type of business all over the world have to rework and bring up to date their information technology to meet customer""s requirements and thus to be successful in the market. But keeping an information system based on traditionally developed software up to date is at least an expensive undertaking, and in many cases it is an unsolvable problem. Object Oriented Technology or simply Object Technology, often abbreviated xe2x80x9cOOTxe2x80x9d or simply xe2x80x9cOTxe2x80x9d, has the technical potential to overcome the problems associated with development, maintenance, and extension of software applications within a company""s information system and to provide interoperability and adaptability across multiple applications and hardware platforms.
Object Oriented Technology describes a method for the development of operating software as well as application software for a computer system. Contrary to the traditional, non object oriented ways of developing software, Object Oriented Technology comprises and uses preengineered xe2x80x9cmethodsxe2x80x9d and xe2x80x9cobjectsxe2x80x9d for the development of software, comparable to tools and parts for the development of an automobile.
Similar to the development of an automobile, wherein not each required screw is developed individually, but standardized screws are used which can be individually adapted by shortening to the required length, within the development of software, Object Oriented Technology provides a xe2x80x9cclassxe2x80x9d as a kind of software template from which individual xe2x80x9cobjectsxe2x80x9d can be instantiated. These classes are usually stored in a software library or a so called xe2x80x9cclass libraryxe2x80x9d. A class library is simply a collection of several classes stored together in a special filing format called a library.
In Object Oriented Technology an xe2x80x9cobjectxe2x80x9d is a self-contained piece of software consisting of related data and procedures. Data means information or space in a computer program where information can be stored, e.g. a name or an inventory part number. Procedures are parts of a program that cause the computer to actually do something, e.g. the parts of a program which perform calculations or the part of a program that stores something on a computer disk. In Object Oriented Technology, an object""s procedures are called xe2x80x9cmethodsxe2x80x9d.
The concept of an object being a self-contained piece of software having data and procedures inside itself is a new way of developing software. In non object oriented software, most of the data for an entire program is often grouped together near the beginning of the program, and the procedures then follow this common pool of data. This conventional method worked okay for smaller programs, but as soon as a piece of software started to grow and become somewhat complex, it become increasingly difficult to figure out which procedures were using which data. This made it quite difficult and expensive to debug or change traditional software programs.
In Object Oriented Technology it is generally easier to debug, maintain, and enhance object oriented software. The three most popular object oriented programming languages are probably xe2x80x9cC++xe2x80x9d, xe2x80x9cJAVAxe2x80x9d, and xe2x80x9cSmalltalkxe2x80x9d. The concept that both data and methods are contained inside an object is called xe2x80x9cencapsulationxe2x80x9d. Part of the concept of encapsulation is that an object has a predictable way of communicating with other objects, a so called predictable xe2x80x9cinterfacexe2x80x9d or sometimes also called the method contract.
Provided that interface will not be changed, the code or methods inside the object can be changed without disrupting other objects"" ability to interact with that object. For example, a TAX CALCULATION object would have a predictable interface for use by PAYCHECK objects. Provided that interface will not be changed, the detailed program code inside the TAX CALCULATION object could be changed whenever the tax laws changed, and no other objects in the payroll system would have to know anything about such changes.
In Object Oriented Technology the term xe2x80x9cinheritancexe2x80x9d is used to communicate the concept that one object can inherit part of its behavior and data from another object, e.g. since an employee is a type of person, an EMPLOYEE object might inherit the characteristics of a PERSON object, such as having name, birth date, and address data, as well as an EMPLOYEE object might inherit methods for updating and displaying these data.
Even if an object inherits some of its characteristics from other objects, that object can, and usually would, also have its own non-inherited characteristics, e.g. whereas a PERSON object would have an inheritable method to display a person""s address, a PERSON object would probably not have a method for displaying paycheck history, since not all persons get paychecks. Because an EMPLOYEE object could not inherit this method from a PERSON object, an EMPLOYEE object would have to define its own method for displaying paycheck history.
Although Object Oriented Technology clearly seems to be the most sophisticated way for the development, maintenance, and extension of software applications, many companies developing software applications are concerned about the cost and risks involved with the rework of existing applications and with the construction of new applications using Object Oriented Technology. For those software application developers, a technical foundation for software applications has to be built as a tool using Object Oriented Technology as the basis, allowing each developer to develop highly unique software products. This technical foundation is formed by frameworks comprising the basic application structure which software application developers previously had to develop by themselves.
In Object Oriented Technology the term xe2x80x9cframeworkxe2x80x9d is used to describe a reusable set or collection of classes which work together to provide a commonly needed piece of functionality not provided by any of the individual classes inside the framework. Thus a framework defines a specific way in which multiple objects can be used together to perform one or more tasks which no single object performs. In other words, a framework is a reusable, predefined and preengineered bundle of several objects which address a recurring programming problem.
Frameworks provide a way of capturing a reusable relationship between objects, so that those objects do not have to be reassembled in that same relationship every time they are needed. Frameworks provide a way of grouping multiple objects together to perform some function which should not have to be thought through each time at the underlying object level. For example, a PRINT framework would consist of all the objects necessary for a programmer to easily print something on any printer, and would probably include objects for printer selection, spooling to disk or error detection as xe2x80x9cout of paperxe2x80x9d. Frameworks can be regarded as an group of software objects which contain a technical foundation for a software application. For example in the business field of Financial, Logistic and Distribution or Production. Although a framework represents a skeleton of a software application, usually a framework is not an executable software program.
By providing frameworks as the technical foundation for developing software applications, the following problems have to be addressed:
Applications have to support all hardware platforms and related software operating systems relevant on the market. Applications have to fulfill the requirements related to client/server configurations including the requirement for graphical user interfaces and windowing techniques. Also, applications have to offer internet compatibility and access on demand. Furthermore applications have to provide integrated solutions with respect to installed software.
In particular, frameworks need to support flexible interchange of domain algorithms so that application developers and end users can easily configure a business object with specific behavior. In many cases, a default behavior that can be overridden at multiple levels is desirable. For example, the default algorithm used to identify a stock location within a warehouse, where a product is to be retrieved from, may be defined on the company object within the framework but may be overridden for a specific combination of product and warehouse, a specific warehouse, or a specific product.
A software application developer may want to change the path, or may want to allow the end user to select one of many possible paths, used to retrieve an overriding algorithm for a specific business object instance. In addition, the application developer may want to improve the performance of the framework, or allow the end user to do so, by bypassing the override retrieval mechanism. The developer may want to apply both of these optional behaviors to some or all of the objects in his application.
Known from the prior art, see e.g. E. GAMMA et al: xe2x80x9cDesign Patterns: elements of reusable object-oriented softwarexe2x80x9d, Addison-Wesley, 1995, ISBN 0-201-63361-2, are two object oriented design patterns, xe2x80x9cChain of Responsibilityxe2x80x9d and xe2x80x9cStrategyxe2x80x9d. The Strategy pattern defines a mechanism to supply multiple replacable algorithms within an object oriented design but the Strategy pattern in isolation is insufficiently flexible as it does not enable the ability to selectively override algorithms on a per-object basis. The Chain of Responsibility pattern provides this ability to override a domain algorithm. In its standard form, however, the Chain of Responsibility is fixed and is defined through direct linkage between the objects in the chain.
Within the accompanying figures, representation standards for classes, objects, relationships etc. are used at least partly according to Grady Booch: xe2x80x9cObject-Oriented Analysis and Design with Applicationsxe2x80x9d, second edition, The Benjamin/Cummings Publishing Company, Ind., Redwood City, Calif., USA.
It is an object of the present invention to provide a technical foundation for the development of software applications using Object Oriented Technology which overcomes the above discussed problems.
It is a further object of the present invention to provide a framework supporting flexible interchange of domain algorithms.
It is a further object of the present invention to provide a framework which allows the modeling of businesses with a multiple level organizational structure.
The present invention solves this object with methods and apparatus as layed down in enclosed independent claims. Particular embodiments of the present invention are presented in the respective dependent claims.
In particular, the present invention provides a framework to be used for developing a software system, e.g. for a business application, said framework using the concept of a Chain of Responsibility design pattern, characterized in that said Chain of Responsibility design pattern concept is abstracted so that a separate class hierarchy defines a set of encapsulated Chains of Responsibility. This has the advantage that the Chain of Responsibility is not limited to objects which are directly linked to each other. Furthermore it is advantageous, that multiple independently defined chains can be implemented and selected on a per-object basis. Thus, the invention supports all of the above requirements relating to flexible interchange of domain algorithms in an efficient and flexible manner.
Objects in the retrieval path do not directly hold instances of Strategy objects as attributes. Instead, these objects are held as properties within an object""s Property Container, as described in the patent application xe2x80x9cProperty Container Type Objectsxe2x80x9d, filed with the European Patent Office, application number 96117940.5. The Chain of Responsibility implementations are thus not limited to using instances of those classes which were defined by the framework to directly hold Strategy objects. This gives the application developer a great deal of flexibility in defining their own retrieval algorithms, including using other framework defined classes and also classes which the application has introduced assuming these application classes are defined to support the Property Container.
In a particular embodiment of the invention the Chain of Responsibility class hierarchy is also implemented using the Strategy pattern so that any one of the alternative retrieval algorithms may be associated with a domain object. In a further particular embodiment, the Strategy class representing the domain algorithm is itself a subclass of the Chain of Responsibility base class, and the Chain of Responsibility""s base class public interface directly exposes the domain algorithm""s Interface. This allows a domain object to be configured with a specific algorithm retrieval implementation, providing a more flexible behavior, or directly with a specific algorithm providing a faster run-time behavior. Such flexibility is crucial in a framework which must allow software application developers to tailor specific applications to widely disparate requirements sets and operating environments.